Skip to content

feat: introduce GatewayConfig CRD for gateway-scoped configuration #1623

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
sqaisar wants to merge 3 commits into
base: main
Choose a base branch
from
Open

feat: introduce GatewayConfig CRD for gateway-scoped configuration #1623

sqaisar wants to merge 3 commits into from
+2,035 −9

Conversation

@sqaisar
Copy link

@sqaisar sqaisar commented Dec 5, 2025 •
edited
Loading

Description

Introduce GatewayConfig CRD for gateway-scoped configuration of the external processor. Adds controller lifecycle handling (including finalizer management), deprecates AIGatewayRoute-level resource configuration in favor of GatewayConfig, and updates docs with migration guidance and new options.

Example

apiVersion: aigateway.envoyproxy.io/v1alpha1
kind: GatewayConfig
metadata:
  name: my-gateway-config
  namespace: default
spec:
  extProc:
    env:
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: "http://otel-collector:4317"
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "512Mi"
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: default
  annotations:
    aigateway.envoyproxy.io/gateway-config: my-gateway-config
spec:
  gatewayClassName: envoy-gateway
  listeners:
    - name: http
      protocol: HTTP
      port: 8080

Related Issues/PRs (if applicable)

Fixes [1]

Special notes for reviewers (if applicable)

Docs, controller, and CRD changes included; route-level resources are deprecated—see migration guidance in docs.

1: #1552

@sqaisar sqaisar requested a review from a team as a code owner December 5, 2025 19:25
@dosubot dosubot bot added the size:XXL This PR changes 1000+ lines, ignoring generated files. label Dec 5, 2025
@sqaisar sqaisar force-pushed the main branch 4 times, most recently from d26095e to 8984f5b Compare December 5, 2025 19:37
mathetake
mathetake reviewed Dec 5, 2025
View reviewed changes
Copy link
Member

@mathetake mathetake left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for taking a shot at this!

nacx
nacx reviewed Dec 6, 2025
View reviewed changes
Copy link
Member

@nacx nacx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just reviewed the API for now and left one comment.

Apart from that, this GatewayConfig object is only relevant for Kubernets, but not in standalone modes (at least for now). Would it make sense to convey that in the API? For example, the Envoy Gateaay infrastructure resources have the "provider" concept and settings are under a kubernetes config know.

Something like:

apiVersion: aigateway.envoyproxy.io/v1alpha1
kind: GatewayConfig
metadata:
  name: comprehensive-config
  namespace: default
spec:
  kubernetes:  
    extProc:
      env:
        (...)

or

apiVersion: aigateway.envoyproxy.io/v1alpha1
kind: GatewayConfig
metadata:
  name: comprehensive-config
  namespace: default
spec:
  extProc:  
    kubernetes:
      env:
        (...)

WDYT?

api/v1alpha1/gateway_config.go
// ExtProc defines the configuration for the external processor container.
//
// +optional
ExtProc *GatewayConfigExtProc `json:"extProc,omitempty"`
Copy link
Member

@nacx nacx Dec 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about using the EnvoyGatway's KubernetesContainerSpec type instead?
This way we already get all the config fields in the container, and better align with a known API users may be already using to configure the EnvoyProxy resource.

Copy link
Author

@sqaisar sqaisar Dec 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This actually makes more sense to use the KubernetesContainerSpec from EnvoyGatway's . I'll update this.
And for the above change I'm not sure if I understand this, if this gatewayconfig is only being used in kubernetes or there are plans to create other provider types apart from kubernetes?

@sqaisar
feat: introduce GatewayConfig CRD for gateway-scoped configuration
d93fec7 
This commit adds the GatewayConfig custom resource definition (CRD) to manage configuration for the AI Gateway external processor. It allows users to define environment variables and resource requirements at the gateway level, enhancing flexibility and reusability across multiple gateways. The AIGatewayRoute's resource configuration is now deprecated in favor of this new approach.

Additionally, the GatewayConfig controller is implemented to handle the lifecycle of GatewayConfig resources, including finalizer management to prevent accidental deletions while still referenced by Gateways.

Documentation updates are included to reflect the new configuration options and migration guidance from the deprecated route-level settings.

Signed-off-by: Shabab Qaisar <[email protected]>
Signed-off-by: Shabab Qaisar <[email protected]>
@sqaisar
refactor: update GatewayConfig controller to remove finalizer management
bc64bbe 
This commit refactors the GatewayConfig controller to eliminate finalizer management, simplifying the lifecycle handling of GatewayConfig resources. The controller now focuses on notifying referencing Gateways of changes without blocking deletion based on references.

Additionally, the documentation has been updated to reflect these changes, including the removal of finalizer behavior descriptions from the API and capability documentation.

Signed-off-by: Shabab Qaisar <[email protected]>
Signed-off-by: Shabab Qaisar <[email protected]>
@sqaisar
refactor: update GatewayConfig controller to remove finalizer management
de09f14 
This commit refactors the GatewayConfig controller to eliminate finalizer management, simplifying the lifecycle handling of GatewayConfig resources. The controller now focuses on notifying referencing Gateways of changes without blocking deletion based on references.

Additionally, the documentation has been updated to reflect these changes, including the removal of finalizer behavior descriptions from the API and capability documentation.

Signed-off-by: Shabab Qaisar <[email protected]>
Signed-off-by: Shabab Qaisar <[email protected]>
@sqaisar
Copy link
Author

sqaisar commented Dec 6, 2025

Thank you for taking a shot at this!

Thankyou for quickly reviewing the changes. I've resolved all of them. Please take a look.

@mathetake mathetake mentioned this pull request Dec 6, 2025
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@nacx nacx nacx left review comments

@mathetake mathetake mathetake left review comments

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

size:XXL This PR changes 1000+ lines, ignoring generated files.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@sqaisar @nacx @mathetake